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METHODS AND SYSTEMS FOR AUTOMATED DATA COLLECTION AND 

ANALYSIS 



FIELD OF THE INVENTION 

[0001] The present invention relates generally to automated data collection 
and analysis and, more particularly, to a system and method for managing 
documentation for commercial transactions. 

DESCRIPTION OF THE INVENTION BACKGROUND 

[0002] Commercial mortgage loan servicing is a document-intensive business. 
A single loan file may contain many different documents related to the terms of a loan, 
including, for example, security instruments, memoranda, appraisals and the like. Loan 
officers, underwriters, asset managers or other personnel on the lender's staff frequently 
receive and capture data from these documents and report this data for a wide variety of 
uses in the course of originating, servicing, and/or selling commercial mortgage loans and 
assets. 

[0003] In the course of a securitization, the lender or originator typically transfers 
the loan into a legal entity known as a Special Purpose Vehicle (SPV) or a trust. The SPV 
structure provides the investor with protection if the originator becomes bankrupt and 
makes it easier for the originator to classify the transfer of loans or assets as a sale. The 
SPV issues securities whose principal and interest are paid by cash flows generated by 
the loans. The SPV passes the consideration paid by the investors to the originator. The 
securities issued by the SPV are subject to securities laws and regulatory authorities such 
as the Securities and Exchange Commission. As such, it is necessary for the lender who 
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originates the loans to abide by laws, regulations and customs regarding full disclosure of 
information for use by purchasers of the securities. 

[0004] At the time of the sale of the assets to the trust or SPV, the lender must 
make representations and warranties that usually include a statement to the effect that 
there are no material errors in the data and/or documents provided by the lender to 
purchasers for the purpose of evaluating assets. If a material error is found in the data, 
the lender may need to repurchase the loan from the trust. This could potentially cause 
significant losses to the lender and potentially damage the lender's reputation for reliability 
in the securities markets. Furthermore, these representations and warranties may cover 
significant characteristics of the portfolio of loans and exceptions to underwriting policies. 
The support for making many representation and warranty statements lies originally in the 
loan documents and is aggregated in data files by the lender and then delivered to 
investors for use in portfolio analysis. A lender who is unable or unwilling to aggregate the 
data contained in the documents can cause an investor to perform labor intensive due 
diligence on every asset in the portfolio. Such investor due diligence requirements may 
cause the potential investor to discount assets. Other complications can include assets 
that are unprofitable for the lender to sell or which simply cannot be sold due to unknown 
risks. 

[0005] Due to the emphasis on the accuracy and delivery of data and 
documents, it is customary for a lender to hire an accounting firm to audit data files relative 
to source documents contained in the loan file to ensure consistency between source 
documents and all data provided to outside parties via a prospectus, for example. The 
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accounting firm then typically issues a "comfort letter" that notes any discrepancies or 
abnormalities in the data. 

[0006] In one example, a securitization may contain as many as several 
hundred loans, each with several hundred documents. A data file is provided to all 
prospective investors and contains many individual data points that must be tied to a 
specific document in the loan file. Prospectus material, loan sale agreements, and 
economic valuation models are based on this data. Because loans are usually made over 
a long period of time and may come from a number of lenders, a great challenge is 
presented by collecting, validating, standardizing, and distributing data to meet the 
standards required by the securities market. 

[0007] In the typical industry process, documents are accumulated over time 
and then "scrubbed" all at once immediately prior to securitization. In a conventional 
process, it is typical for the lender to accumulate loans through origination and acquisition 
over a period of a year or more. At the point of securitization, the lender reviews all files in 
the portfolio and performs substantial due diligence at great expense to aggregate the 
data into a format suitable to investors. Because documents are presented in a wide 
variety of formats and are handled by many different parties throughout the process, there 
is ample opportunity to misplace or misinterpret documentation. 

[0008] Therefore, there is a need for systems and methods that improve the 
efficiency of the document collection and storage process, ensure accurate transfer of data 
from loan documents into servicing databases for analytical and servicing processes, and 
facilitate the distribution of data and documents to any appropriate user. 
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SUMMARY OF THE INVENTION 
[0009] The present methods and systems include, in one embodiment, a 
computer-assisted method for processing asset-related documents in a database 
having at least one record therein. The method includes reviewing asset-related data 
contained on at least one asset document, receiving the asset document into the 
database on a flow basis, analyzing the contents of the asset document to ensure 
compliance with at least one standard, and providing output data from the record in the 
database. System and computer readable medium embodiments of the methods are 
also provided. 

[0010] In another embodiment, the present methods and systems include a 
computer readable medium having computer executable instructions for performing a 
method for automated aggregation and authentication of asset documents into a 
database. The method includes associating an asset with a record in a database, 
inventorying an asset document into the record in the database on a flow basis, and 
analyzing the contents of the asset document to ensure compliance with a standard. 
The method further includes providing specific information contained in the asset 
document to a user and generating common information from the database. 

[001 1] In another embodiment, the present methods and systems include a 
computer system for automated aggregation and authentication of asset documents. 
The system includes a data input device for receiving first information from an asset 
document associated with an asset from an input source where a plurality of the asset 
documents associated with the asset comprise a record. The system further includes a 
storage device for storing the record, a processor for retrieving comparison data where 
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the comparison data comprises compared common data fields of the stored first 
information from a plurality of the asset documents within the record and for providing 
the comparison data to a user. The processor is used further for: retrieving second 
information, where the second information comprises the asset documents common 
data fields within the record and providing the second information to a user; retrieving 
third information, where the third information comprises data from fields common to the 
multiple records and providing the third information to a user; identifying missing data 
for the asset; and providing a missing data output to notify a user. The system further 
includes a data output device for generating first output information from the processor. 

[0012] In another embodiment, a system is provided that includes a computer 
system for managing, servicing and aggregating commercial mortgage loans. The 
system includes a means for inputting information regarding a plurality of commercial 
mortgage loans, a means for storing the information regarding the commercial mortgage 
loans, and a first query means for collecting information from at least one commercial 
mortgage loan. The system further includes a first query result presentation means for 
presenting the collected information, a second query means for determining if any data 
is missing from the commercial mortgage loan, and a second query result presentation 
means for presenting a missing data notification. The system further includes a means 
for aggregating the information of the commercial mortgage loans wherein the 
aggregating means has an asset analysis means for determining if the commercial 
mortgage loan is prepared for securitization, a means for displaying aggregated 
information, a means for alerting a user if any aggregated information necessary for 
securitization is missing, and a means for extracting information. 



[0013] In another embodiment, a computer-assisted method for automated 
aggregation and authentication of asset documents is provided. The method includes 
associating an asset with a record in a database, inventorying an asset document into 
the associated record in the database in near real time as the asset document becomes 
available to the loan originator, and analyzing contents of the asset document to ensure 
compliance with banking standards for loan securitization. The system further includes 
providing specific information contained in the asset document to a user and generating 
common information from a plurality of the records where the common information is 
generated for the purpose of securitizing the asset into a trust and providing common 
information to potential investors in the trust. 

[0014] In another embodiment, a computer readable medium is provided 
having computer executable instructions for performing a method for processing asset- 
related documents in a database having at least one record therein. The method 
includes reviewing asset-related data contained on at least one asset document, 
receiving the asset document into said database on a flow basis, analyzing contents of 
the asset document to ensure compliance with at least one standard, and providing 
output data from the record in the database. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0015] FIG. 1 is a block diagram showing one embodiment of a system for 
automated collection of document information; 

[0016] FIG. 2 is a block diagram showing the software modules of the system 
shown in FIG. 1; 
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[0017] FIG. 3 is a block diagram showing the analysis module of the server 
system in FIG. 2; 

[0018] FIG. 4 is a block diagram showing the extraction module of the server 
system in FIG. 2; 

[0019] FIG. 5 is a block diagram showing the aggregation module of the 
server system in FIG. 2; 

[0020] FIG. 6 is a record view showing, by way of example, the fields 
comprising the record shown in FIG. 1; 

[0021] FIG. 7 is a flow diagram showing one embodiment of a routine for 
processing data in a method and system for collecting document information; 

[0022] FIG. 8 is a flow diagram showing one embodiment of a routine for 
entering data and scanning a loan document; 

[0023] FIG. 9 is a flow diagram showing one embodiment of a routine for 
extracting facsimiles of asset documents stored in a record; 

[0024] FIG. 10 is a flow diagram showing one embodiment of a routine for 
aggregating data from several records and allowing a user to determine the manner in 
which the aggregated data is presented; 

[0025] FIG. 1 1 is a block diagram showing the hardware components of the 
system shown in FIG. 1; 

[0026] Figures 12A and 12B are examples of graphical user interfaces of one 
embodiment of the system shown in FIG. 1; 

[0027] FIG. 13 is an example of a graphical user interface of one embodiment 
showing details of one of the fields shown in FIG. 12A; 
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[0028] FIG. 14 is an example of a graphical user interface used in the entry of 
data and generation of markers for asset documents in one embodiment; 

[0029] FIG. 15 is an example of an output from a user selection from the 
graphical user interface shown in FIG. 14; 

[0030] FIG. 16 is an example of a graphical user interface used for viewing an 
electronic facsimile of an asset document scanned into the database; 

[0031] FIG. 17 is an example of a graphical user interface template used in 
one embodiment of the system for entering asset document information into the 
database; 

[0032] FIG. 18 is an example of a graphical user interface for selecting a loan 
portfolio or set of loans to produce a report or datafile; 

[0033] FIG. 19 is an example of a graphical user interface for selecting a 
report from a user selection shown in FIG. 18; 

[0034] FIG. 20 is an example of a graphical user interface for creating and 
storing criteria used in retrieval of electronic facsimiles of asset documents stored in the 
database; 

[0035] FIG. 21 is an example of a graphical user interface of an indexing 
scheme created by the system for the electronic facsimiles retrieved as shown in FIG. 
20; 

[0036] FIG. 22 is an example of a graphical user interface for selecting report 
templates created from the asset data stored in the database; and 

[0037] FIG. 23 is an example of a report generated from a selection shown in 
FIG. 22. 
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DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION 
[0038] The present inventor concluded that what are needed are methods and 
systems that allow the lender to efficiently accumulate data efficiently on a flow basis — 
near real time as the asset documents become available to the loan originator or another 
party concerned with loan maintenance — over the course of time so that the data is readily 
available and substantially reliable at the time of securitization. The inventor determined 
that improved methods and systems are needed so that when the loan is originated, 
substantially all available documents are entered into the system, and the system, in turn, 
can determine if the data meets applicable standards for securitization. As further 
documents pertaining to the loan become available, the documents can also be entered 
into the system on a flow basis. Methods and systems are needed that flow information 
into the database in near real time and provide a method to ensure data integrity. Such 
methods and systems would reduce due diligence on the lender's behalf in comparison to 
industry averages, and would improve the integrity of the collected data. Such methods 
and systems would also allow the lender to concentrate efforts on effecting the transaction 
and attend to investor needs, rather than expending costly resources on simply attempting 
to collect, organize and process data. 

[0039] Thus, there is a need for systems and methods for providing rigorous 
collection of loan documentation before a loan is sold into a trust or SPV for securitization. 
This rigorous collection can occur on a flow basis-in near real time-as the documents 
pertaining to the loan become available to those concerned with loan origination and 
maintenance. 



[0040] There is a further need for systems and methods by which the 
information gleaned from the loan documents can be validated against applicable 
standards in near real time as the loan documents become available to those concerned 
with loan origination, maintenance and securitization, thereby reducing or eliminating 
costly due diligence prior to securitization. 

[0041] There is a further need for systems and methods by which data points 
are aggregated across several loans into a single datafile, where the datapoints comprise 
information taken from a plurality of loans that are to be securitized and the datafile is 
compiled for the purpose of corroborating the representations and warranties that are to be 
made by the originator. The aggregated data provides information necessary to satisfy 
regulations pertaining to full disclosure of material information in loan securitizations and 
relevant information that potential investors may require. 

[0042] There is a further need for systems and methods that eliminate the need 
to manually aggregate data pertaining to individual loans or a plurality of loans. Once all of 
the information is collected and validated there should be little or no further need for costly 
manual substantiation of any data point contained in the database or any representation or 
warranty made regarding the loans. 

[0043] There is a further need for systems and methods to provide a single 
source of information regarding loan portfolios where the systems and methods capture, 
validate, and distribute reliable data to investors, attorneys, investment bankers, and many 
other participants involved in the securitization process. 

[0044] For the foregoing reasons, there is a need for methods and systems that 
can reduce the amount of due diligence required for loan securitization, improve the 
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reliability of asset information provided to potential investors and provide a clearinghouse 
system for asset document information. 

[0045] As used herein, "asset" includes an item of value, for example a debt 
secured by real or personal property. 

[0046] "Flow basis" indicates that information is analyzed and entered into a 
database as the information becomes available to a loan originator or someone 
responsible for loan maintenance or any other user of the system and method described 
herein. With respect to flow basis, information can be collected and validated based on 
securitization standards. It can be appreciated that the data can be collected 
independent of its end use. 

[0047] The term "standard" used herein comprises, for example, applicable 
banking, legal, customary and trade standards for asset securitization and securities 
issuance, or the uniformity of preexisting data. 

[0048] FIG. 1 is a block diagram showing one embodiment of a system 10 for 
automated collection of document information which can be, for example, commercial 
mortgage loan information. A plurality of documents 1 are entered into a database 13 
through an input device 3 such as, for example, an optical scanner or a graphical user 
interface residing on a PC. However, any form of data entry device capable of 
communicating with a server 5 can be used, as is known in the art. The database 13 
resides on the server 5, where the database contains records 1 1 that store the plurality 
of documents 1. The individual records 11 are associated with individual assets. The 
database 13 may be a commercial relational database such as Microsoft® Access and 
can contain preprogrammed modules 9. The database 13 is capable of sorting, 
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indexing and generating reports through output device 7 which may be, for example, a 
CD writer, a printer, a display on a PC, and the like. The database 13 includes a high- 
capacity storage medium configured to store individual asset records and related loan 
information. In one aspect, the database 13 is configured as a set of high speed, high- 
capacity hard drives, such as organized into a Redundant Array of Inexpensive Disks 
(RAID) volume, for example. However, any form of volatile storage, non-volatile 
storage, removable storage, fixed storage, random access storage, sequential access 
storage, permanent storage, erasable storage, and the like would be equally suitable. 

[0049] In one embodiment, the documents 1 include commercial mortgage 
loan documents. However, the system 10 can accommodate a wide range of document 
types used in other areas of asset securitization or in the banking system as well as 
other document management applications. One skilled in the art can recognize the 
applicability of the present methods and systems to these related document types. 

[0050] As the documents 1 become available they are entered into the 
database 13 on a flow basis. This is preferably to be done within five days of receipt of 
the document by the loan originator or another party concerned with loan maintenance, 
more preferably to be done within 1 day of receipt of the document by the loan originator 
or another party concerned with loan maintenance, most preferably to be done upon 
receipt of the document by the loan originator or another party concerned with loan 
maintenance, thereby allowing a user to enter the documents on a flow basis over time. 
Flow basis is in contrast to accumulating all of the documents over a period, typically 
extending six months to a year, and then entering them all at once. 
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[0051] In one aspect, the server 5 can be a general purpose, programmed 
digital computing device consisting of a central processing unit (CPU), random access 
memory (RAM), non-volatile secondary storage, such as a hard drive or CD-ROM drive, 
network interfaces, and peripheral devices, including user interface means, such as 
keyboard and display. Program code, including software programs and data are loaded 
into the RAM for execution and processing by the CPU and results are generated for 
display, output, transmittal, or storage. In the described embodiment, the individual 
server can be an Intel-Pentium® based server system such as is available, for example, 
from Dell Computers, Austin, Texas, or Compaq Computers, Houston, Texas. The 
system is preferably equipped with at least 128MB RAM, at least 100GB hard drive 
capacity, data backup facilities, and related hardware for interconnection to an intranet 
and the Internet. 

[0052] FIG. 2 is a block diagram showing the software modules 9, 19, 21, 23 
of the system shown in FIG. 1. Each module is a computer program written as source 
code in a conventional programming language, such as Visual Basic or C++, for 
example, and is executed by the CPU in object or byte code as is known in the art. The 
individual modules 9, 9A, 9B, 9C, 9D, 9E, 19, 21, 23 may also be written in a 
programming language provided with a commercial database program such as 
Microsoft® Access. The various implementations of the source code and object code 
can be held on a computer readable medium, including, for example, a transmission 
medium in a carrier wave. There are four basic software modules which functionally 
define, for convenience of disclosure, the operations performed by the server system 5: 
a database module 9, an extraction module 19, an aggregation module 21, and an 
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analysis module 23. In one embodiment, these modules 9, 19, 21 , 23 are executed on 
a single server although a single or multiple component server could also perform this 
functionality. The individual module functions are described in more detail in FIGS. 3, 4, 

5. 

[0053] For each asset, the database 13 receives asset document information 
15 pertaining to that asset, and the database module 9 stores the information 15 in 
record form in the database 13. The database module 9 organizes the asset document 
information 15 in the database 13. The database module 9 further provides the facilities 
for efficiently storing and accessing the asset information 15 that is collected on a flow 
basis. The asset document information is stored in a record 1 1 (as shown in FIG. 1 ) 
and organized into fields (an example of which is shown in FIG. 6). The database 
server 5 performs the functionality of the database module 9. Any type of database 
organization can be utilized, for example, a flat file system, hierarchical database, a 
relational database, or distributed database, such as provided by database vendors 
Microsoft® or Oracle®. In alternative embodiments of the present methods and 
systems, conventional spreadsheet software and Lotus Notes® applications can be 
employed. 

[0054] The analysis module 23 analyzes the asset document information 15 
that is entered into the database 13. The analysis module 23 compares the asset 
document information 15 to a preprogrammed standard to ensure compliance. The 
preprogrammed standard may be, for example, an applicable banking industry standard 
for commercial mortgage loan information, a legal standard for mortgage documents, an 
applicable banking standard for securitization of commercial mortgage loans, and the 
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like. The asset document information 15 is further compared to information stored in 
the database 13 to determine a data mismatch. Through the use of the asset document 
information 15 entered on a flow basis, the analysis module 23 ensures that asset 
document information 15 entered into the database 13 meets applicable standards for 
asset securitization as the asset data is accumulated, reducing the need for manual 
analysis of the asset information when the asset is securitized into a trust or SPV. The 
analytic operations of the analysis module 23 are further described below with reference 
to FIG. 3. The server 5 performs the functionality of the analysis module 23. 

[0055] The aggregation module 21 collects data contained in a plurality of 
database records 1 1 . A user of the system, for example, may desire information 
contained in one field of multiple database records. The aggregation module 21, 
working in conjunction with the database module 9, compiles the information contained 
in the various records into one datafile. The functionality of the aggregation module 21 
is performed by the server 5. 

[0056] The extraction module 19 provides automated information output upon 
request of a system user. The output could be, for example, electronic mail, a printed 
report, information that is written to a CD or information that is published on a website or 
any other means known to those skilled in the art. In the described embodiment, the 
output is presented in a tiered manner. The user requested information 17 can, for 
example, be displayed on a PC monitor. The information 1 7 could further be sent via 
electronic mail upon user request after display on a monitor. The information 17 could 
further be written to a CD where the size of the information 1 7 is too large for 
transmission through standard electronic mail systems. Finally, the information 17 
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could be made available to another server for display on a website that provides 
multiple users access to the information 17. The server 5 performs the functionality of 
the extraction module 1 9. 

[0057] FIG. 3 is a block diagram showing the analysis module 23 of the server 
5 of FIG. 2. The analysis module 23 contains three functional submodules: the 
database interface module 9E and the database query module 9B, and the comparison 
module 33. The database interface module 9E and query module 9B may be 
preprogrammed in a commercial database such as Microsoft® Access where a user 
can tailor them to specific needs, as is known in the art. The purpose of the comparison 
module 33 is to compare, for example, commercial mortgage loan document information 
27, as shown, to a standard preprogrammed into the comparison module 33. This 
standard, as explained above, may be a banking industry standard or a legal standard. 
The comparison module 33 further compares the information 27 to information 
contained in the record 1 1 corresponding to that particular asset. The analysis module 
23 can operate either in batch mode wherein an alert 37 is generated for information 27 
from a group of asset documents or in a dynamic mode wherein the alert 37 is 
generated in real time as the information 27 is entered into the database 13. 

[0058] The analysis module 23 receives information 27 from, for example, 
commercial mortgage loan asset documents. This information is entered into the 
database 13 via a database interface module 9E. The interface module 9E calls the 
comparison module 33 based on a user selection of a particular asset. The comparison 
module 33, in turn, calls a database query via the database query module 9B that 
locates the appropriate record 1 1 associated with the asset. The comparison module 
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33 compares the information 27 to a preprogrammed standard, a banking standard or 
legal standard, for example. If the information 27 does not meet that standard, the alert 
37 is generated that is presented to a user via the interface module 9E. The standard 
may be programmed in the form of a user-selected template for data entry into a 
particular asset record, or a software object called by the comparison module 33 with 
preprogrammed logic reflecting the appropriate standard. If the information 27 is 
already contained in the database in another field of the record 1 1 , the comparison 
module 33 pulls this preexisting information via the query module 9B and compares it to 
information 27. For example, with regard to commercial mortgage loans, building 
square footage contained in the mortgage document can be compared against the 
square footage in the building inspection. The comparison module compares the 
square footage information contained in the record 1 1 and, in the event of a mismatch, 
an alert 37 can be generated and displayed to the user. 

[0059] FIG. 4 is a block diagram showing the extraction module 19 of the 
server system in FIG. 2. The extraction module 19 contains three submodules: the 
database interface module 9E, the information extraction and format module 45 and the 
database query module 9B. The database interface module 9E and query module 9B 
function in the manner stated above with respect to the analysis module 23. An 
information request 49 is sent to the extraction and format module 45 via the interface 
module 9E. The extraction and format module 45 calls the database query module 9B 
to find the appropriate record 1 1 in the database (not shown). The extraction and 
format module 45 extracts the requested information 49 from the record into a 
temporary datafile and then formats the extracted data in a manner requested by the 
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user. The interface module 9E may contain preprogrammed graphical user interface 
screens programmed to display the extracted and formatted information. The interface 
module 9E may further contain options to print the extracted information, for example, or 
send the information to a CD or electronic mail. 

[0060] FIG. 5 is a block diagram showing the aggregation module 21 of the 
server system in FIG. 2. The aggregation module 21 collects data contained in a 
plurality of database records 1 1 . A user of the system, for example, may desire 
common information contained, for example, in one field of multiple database records. 
The user generates a request for information 57 that is sent to the information 
compilation module 59 via the database interface module 9E. The information 
compilation module 59, in turn, calls the query module 9B. The compilation module 59 
and the query module 9B determine what records 1 1 must be queried and collected to 
satisfy the request 57. The query module 9B indexes the database based upon the 
request 57. Upon indexing of the records containing the requested common 
information, the compilation module 59 extracts the data contained in the fields of the 
records 1 1 and writes it to a temporary datafile. An example of this is a request by a 
user for all property balance sheets contained in a plurality of database records. The 
compilation module 59, in conjunction with the query module 9B, indexes the database 
on the field of property balance sheets. The datafile is then displayed via the interface 
module 9E in the form of aggregated common information 51 as requested. 

[0061] FIG. 6 is a record view illustrating the fields comprising an example 
record 1 1 shown in the database 13 of the system of FIG. 1 . Each record 1 1 is 
illustrative of some of the information typically required to securitize an asset or loan into 
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a trust or SPV. For example, for a commercial mortgage loan, information associated 
with the following documents can be recorded in the database record 11: the asset 
name 61 , appraisal 63, promissory note 67, escrow agreement 71 , rent roll 75, and 
operating statement 79. Pertinent information is taken from documents 63, 67, 71 , 75, 
and 79 and entered into their corresponding representative data fields 65* 69, 73, 77, 
and 81, respectively. The list is illustrative, but not exhaustive, of the information 
typically required for a commercial mortgage loan and can be modified by one skilled in 
the art to accommodate other fields for any financial instruments suitable for 
securitization. From these fields, many forms of investor information can be generated 
as is known in the art. The fields shown in FIG. 6 can be common to two or more 
records contained in the database 13 and can serve as an index for the database query 
module 9B. The records are typically indexed based on field 61 and stored in that 
manner. The information compilation module 59 can pull information contained in a 
single field or multiple fields. 

[0062] Common information can be stored in more than one field of the record 
11. For example, the appraisal value contained in appraisal field 63 must match the 
appraisal value entered as part of the promissory note information 67 entered in 
representative data fields 69. The comparison module 33 described above compares 
the information stored in these fields upon entry of data into either field and generates 
the alert 37 if the appraisal value does not match. 

[0063] FIG. 7 is a flow diagram showing one embodiment of a method for 
inputting data into either an existing record or creating a record and then inputting data 
on a flow basis. The input data is compared to preexisting data and to a standard. In 
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one aspect, the method can be implemented as a conventional computer program for 
execution by the server system 10 shown in FIG. 1 . As a preparatory step, the user 
determines in step 95 if this is a preexisting asset matching a record 1 1 in the database 
13 (as shown in FIG. 1). If the record exists, the database executes a query and 
retrieves the record in step 99. The user then inputs the asset data in step 101 into the 
record. The entered data is then compared to preexisting data in step 105 to determine 
if there is a data mismatch in step 107. In the event of a mismatch, the user is alerted in 
step 109. If the record does not exist, the user creates the record in step 97 
corresponding to the asset and then inputs the data in step 101 into the database. 
Upon successful data entry, the entered data is compared to a standard in step 1 1 1 to 
ensure compliance with the standard. Upon comparison to the standard in step 113, 
the program generates, for example, an alert, a report or other like notification if the 
data does not meet the standard in step 115. The asset documents are entered into the 
database as soon as they become available to a user, or in a reasonable time 
thereafter, and are compared to a standard and preexisting data as the asset 
information is entered into the database. Thus, it can be seen that the information is 
flowed into the database or entered on a flow basis. 

[0064] FIG. 8 is a flow diagram showing one embodiment of a routine for 
entering data and then scanning a loan document. The purpose of this routine is to 
illustrate data entry into the database where the data is entered through a graphical 
user interface template. As a preparatory step, the user selects the applicable template 
for the document type in step 117. The program then displays the template to the user 
in step 119. The user inputs the asset or record name or, for example, selects the asset 
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from a menu in step 121 . The database then queries the record in step 123 from the 
database associated with the asset. The user then inputs data into the required fields in 
step 125 and the program, in turn, stores the input information in the record in step 127. 
The program then prompts the user in step 129 to scan the document. If the user opts 
to scan the document, an electronic facsimile of the asset document is created and 
associated with that field of the asset record in step 1 31 . 

[0065] FIG. 9 is a flow diagram showing one embodiment of a routine for 
extracting electronic facsimiles of asset documents stored in a record. The purpose of 
this routine is to extract copies of original documents stored in a record 1 1 associated 
with an asset in a database 13. The user, through the database interface, requests 
copies of original asset documents in step 133. The user selects the applicable asset in 
step 135. The appropriate record associated with the asset is queried and retrieved 
from the database in step 137. The required documents are extracted from the 
retrieved records in step 139 and displayed as a list to the user in step 140. The user 
selects the means for extracting the electronic facsimiles of the documents in step 141 , 
where the means include, for example: displaying on a monitor in step 143, hard copy 
printing in step 147 or writing the information to a CD, electronic mail or website in step 
145, for example. 

[0066] FIG. 10 is a flow diagram showing one embodiment of a routine for 
aggregating data from several records and then allowing a user to determine the 
manner in which the aggregated data is presented. The purpose of this routine is to 
provide information regarding a portfolio of assets to potential investors where the 
assets form the basis of the securities issued from a trust or SPV. As a preparatory 
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step, the user selects the report type desired in step 149. The records required to form 
the report are retrieved from the database in step 151 . The data comprised in the 
records are collected from the pertinent fields of the retrieved records in step 153 and 
stored in a datafile in step 157. The user then determines the manner by which the data 
are to be presented in step 159, examples of which include: displayed as one file in step 
163, generated in a report in step 165, written to a CD, sent via an electronic mail or 
published on a website in step 161. 

[0067] FIG. 11 is a block diagram showing one illustrative embodiment of the 
hardware components of the system shown in FIG. 1. A remote PC 179 can be 
equipped with a printer 181, a scanner 177 and a CD optical drive 175. The 
components comprise a workstation 169 capable of communicating with the Internet 
171. Each workstation is preferably equipped with 64MB RAM, 10GB hard drive 
capacity and related equipment. In addition, the workstations 169 are also Intel 
Pentium®-based personal computer workstations available from, for example, Dell or 
Compaq. The workstations 169 and 167 each further comprise a programmed digital 
computing device consisting of a central processing unit (CPU), random access 
memory (RAM), non-volatile secondary storage, such as a hard drive or CD-ROM drive, 
network interfaces, and peripheral devices, including user interface means, such as 
keyboard and display. Program code, including software programs and data are loaded 
into the RAM for execution and processing by the CPU and results are generated for 
display, output, transmittal, or storage. The server 5 is a general purpose, programmed 
digital computing device consisting of a central processing unit (CPU), random access 
memory (RAM), non-volatile secondary storage, such as a hard drive or CD-ROM drive, 
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network interface, and peripheral devices, including user interface means, such as 
keyboard and display. Program code, including software programs and data are loaded 
into the RAM for execution and processing by the CPU and results are generated for 
display, output, transmittal, or storage. In the described embodiment, the individual 
server is an Intel-Pentium® based server system such as is available from Dell or 
Compaq. The system is preferably equipped with at least 128MB RAM, and at least 
100GB hard drive capacity, data backup facilities, and related hardware for 
interconnection to an intranet and the Internet. Other types of server and workstation 
systems including minicomputers, mainframe computers, supercomputers, parallel 
computers, digital data processors and the like are equally suitable, as is known in the 
art. 

[0068] Asset data are communicated from the workstations 1 69 and 1 67 via 
the Internet 171 or the intranet 173 to the router 174 and ultimately to the server 5 
where the database 13 resides. However, any type of communications link could be 
used including a serial link, data telephone link, satellite link, radio-frequency link, 
infrared link, fiber optic link, coaxial cable link, television link, and the like, as is known in 
the art. Also, the intranet 173 is comprised of a server or plurality of servers that are 
typically minicomputers or Intel Pentium® based PCs and preferably equipped with at 
least 128MB RAM, and at least 100GB hard drive capacity, data backup facilities, and 
related hardware for interconnection to the Internet 171 . The connection 172 is typically 
a T-1 network router such as manufactured by Cisco Systems or Marconi, for example. 
However, any type of interfacing device suitable for interconnecting a server to a 
network could be used including a data modem, cable modem, network interface, serial 
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connection, data port, hub, frame relay, digital PBX, CITRIX Winframe®, and the like, as 
is known in the art. 

[0069] In the present embodiment, asset data is input via workstations 169 
and transmitted via the Internet 170 through the connection 172 and to the intranet 
server 173. Information is also input through workstations 167 connected directly to the 
intranet server 173. The information can be routed 174 to the database server 5 for 
storage in the database 13. To ensure reliable data exchange, the intranet server can 
implement a TCP/IP protocol stack, although other forms of network protocol stacks, 
such as HTTP, are suitable. 

[0070] Referring now to Figures 12A and 12B, FIG. 12A is an example of a 
graphical user interface of one embodiment of the system shown in FIG. 1. As shown, 
the screen 182 contains a directory tree 185 that corresponds, in part, to the fields of 
the database record 1 1 (as shown in FIG. 6) and is an example of one embodiment of 
the database interface module 9E shown in Figures 3, 4 and 5. A dialogue box 217 
shows an example of a further embodiment of the interface module 9E where 
information is entered into a field of record 1 1 . The dialogue box 217, for example, 
demonstrates the user selecting the appropriate asset 183 associated with the record 
and by this action the program sets up an automatic scheduler 218, that can be used, 
for example, to alert the user to periodically obtain new financial statements from the 
borrower as required by the loan agreement. The system can further create individual 
tracking records for each asset document entered. 

[0071] FIG. 13 is an example of a graphical user interface of one embodiment 
showing details of one of the fields shown in FIG. 12A. This split screen 184 is 
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displayed based upon the user selection in dialogue box 217 as shown in FIG. 12A and 
is an example of one embodiment of the database interface module 9E shown in 
Figures 3, 4 and 5. In this example of a split screen 184, a due date for document 
collection 219 is established and if the user currently has the asset document an end 
date 221 is entered. This functionality of the interface screen 182 facilitates orderly 
document collection and allows the user to enter the documents as they become 
available on a flow basis over time instead of entering all of them just prior to loan 
securitization. 

[0072] FIG. 14 is an example of a graphical user interface used in the entry of 
data and generation of markers for asset documents in one embodiment. The program 
displays a pop-up window 223 that facilitates scanning of the asset document to create 
an electronic facsimile for entry into the database 13. The pop-up window 223 further 
enables a user to create a bar code sheet or unique identification marker to affix to an 
asset document. In the embodiment displayed in FIG. 14, the user selects bar code 
sheet and the program produces a unique marker document 225, as shown in FIG. 15, 
containing an identification marker that is affixed to the document prior to scanning. In 
this embodiment, the system facilitates tracking of documents via optical means after 
the unique marker document 225 is affixed to the asset document. 

[0073] FIG. 16 is a graphical user interface for viewing an electronic facsimile 
of an asset document scanned into the database. The dialogue box 223, as shown in 
FIG. 14, allows a user to view an electronic facsimile of an asset document 227 after the 
document is scanned into the system. It is appreciated from the screen view 182 and 
further from the directory tree 185 that any image stored for a given field of record 1 1 is 
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capable of viewing via dialogue box 223. A user selects an asset 183 causing a 
directory tree 185 for that asset to display. The user then causes the dialogue box 223 
to display and selects image to view the asset document associated with that field in the 
record 11 associated with asset 183. 

[0074] FIG. 17 is an example of a graphical user interface template used in 
one embodiment of the system for entering asset document information into the 
database 13. To efficiently enter asset data into the database 13 and to properly 
analyze the contents of the asset data, in one embodiment, the system provides 
templates 230 for a document type selected from the directory tree 185. The template 
230, in this example, serves a dual purpose as a database interface and data analyzer. 
Upon selection of a field associated with an asset document type from the tree 185, the 
system displays subfields commonly found in that type of asset document. These 
subfields, for example subfields 229, 231 and 233, require pertinent data to service and 
sell the loan into a trust or SPV, for securitization. 

[0075] FIG. 18 is an example of a graphical user interface for selecting a loan 
portfolio or set of loans to produce a report or datafile. The user causes dialogue box 
237 to display. In one embodiment, the dialogue box 237 accepts user input 239 and 
causes a module to execute that aggregates data in accordance with user input 239. in 
one embodiment, for example, the user requests data derived from source asset 
documents contained in a series of assets (records 1 1 ), for example, all loan terms and 
property values for a collection of assets. The program, utilizing the compilation module 
59 as shown in FIG. 5, generates a datafile that presents loan terms as stated in each 
promissory note and property values stated in each appraisal. 
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[0076] FIG. 19 is an example of a graphical user interface for selecting a 
report from a user selection shown in FIG. 18. The datafile produced in FIG. 18 is 
presented to the user in a dialogue box 243 and contains a series of preprogrammed 
reports 244. The user has the option of viewing a report from the list 244, sending the 
report via e-mail 245 or printing the report. The directory tree 241 comprises a list of 
assets, each asset corresponding to a record 1 1 in the database 13. 

[0077] FIG. 20 is an example of a graphical user interface for creating and 
storing criteria used in retrieval of electronic facsimiles of asset documents stored in the 
database 13. The user selects a loan portfolio 246 from a directory tree 185. The user 
can cause a criteria template 248 to display where the user enters the criteria that are, 
in turn, used in retrieving the electronic facsimiles of asset documents. The information 
format and extraction module 45 of the extraction module 19 is utilized to complete the 
electronic facsimile retrieval process. 

[0078] FIG. 21 is an example of a graphical user interface of an indexing 
scheme created by the system for the electronic facsimiles retrieved as shown in FIG. 
20. Screen 250 is displayed after the retrieval of electronic facsimiles of asset 
documents shown in FIG. 20. A directory tree 249 is displayed showing an indexed list 
in hierarchical form, created by the extraction module 19, of all electronic facsimiles of 
asset documents meeting the criteria entered as shown in FIG. 20. The list 249 is then 
transferred to a CD via a conventional CD creation method or the list is saved as a 
webpage where access is granted to authorized remote users as shown in FIG. 1 1 . 

[0079] FIG. 22 is an example of a graphical user interface for selecting report 
templates created from the asset data stored in the database for the purpose of data 
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extraction. This is the dialogue box demonstrated in FIG. 19 and is an example of a 
graphical user interface for generating a report from a user selection shown in FIG. 18. 
The datafile produced in FIG. 18 is presented to the user in a dialogue box 243 and 
contains a series of preprogrammed reports 244. In this example, the user selects 
"view" 245 and further selects a report 255 from the list 244. 

[0080] FIG. 23 is an example of a report generated from a selection shown in 
FIG. 22. A report 257 is created based upon the user's selection from the dialogue box 
243 shown in FIG. 22. The user further has the option of printing a physical copy of the 
report or sending a copy via electronic mail. 

[0081] From the foregoing, it is apparent that the methods and systems 
discussed herein allow a lender to efficiently accumulate data efficiently on a flow basis — 
near real time as the asset documents become available to the loan originator or another 
party concerned with loan maintenance — over the course of time so that the data is readily 
available and substantially reliable at the time of securitization. The systems and methods 
further provide that when a loan is originated, substantially all available documents are 
entered into the system, and the system, in turn, determines if the data meets applicable 
banking standards for securitization. The methods and systems further flow information 
into the database in near real time and provide a method to promote data integrity. Such 
methods and systems reduce due diligence on the lender's behalf in comparison to 
industry averages, and improve the integrity of the collected data. Such methods and 
systems allow the lender to concentrate efforts on effecting the transaction and attending 
to investor needs, rather than expending costly resources on simply attempting to collect, 
organize and process data. 
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[0082] The systems and methods further provide rigorous collection of loan 
documentation before a loan is sold into a trust or SPV for securitization. In accordance 
with the method described, this rigorous collection occurs on a flow basis-in near real time 
as the documents pertaining to the loan become available to those concerned with loan 
origination and maintenance. 

[0083] Finally, the systems and methods validate information taken from a 
plurality of asset documents against applicable standards in near real time as the loan 
documents become available to those concerned with loan origination, maintenance and 
securitization, thereby reducing or eliminating costly due diligence prior to securitization. 

[0084] The term "computer readable medium" is defined herein as understood 
by those skilled in the art. A computer readable medium can include, for example, 
memory devices such as diskettes, compact discs of both read-only and writeable 
varieties, optical disk drives, and hard disk drives. A computer readable medium can 
also include memory storage that can be physical, virtual, permanent, temporary, semi- 
permanent and/or semi-temporary. A computer readable medium can further include 
one or more data signals transmitted on one or more carrier waves. 

[0085] It can be appreciated that, in some embodiments of the present 
methods and systems disclosed herein, a single component can be replaced by multiple 
components, and multiple components replaced by a single component, to perform a 
given function. Except where such substitution would not be operative to practice the 
present methods and systems, such substitution is within the scope of the present 
invention. 
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[0086] Examples presented herein are intended to illustrate potential 
implementations of the present method and system embodiments. It can be 
appreciated that such examples are intended primarily for purposes of illustration. No 
particular aspect or aspects of the example method and system embodiments, 
described herein are intended to limit the scope of the present invention. One skilled in 
the art would readily recognize that the present systems and methods have uses 
outside the commercial loan arena and none of the embodiments presented above are 
meant to limit the scope of applications of the present methods and systems. 
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